The function to createVRGManifestWork will create a new VRG when a
ManifestWork for it does not exist. Ensure that the MW is not present
before creating one, and return an Exists error for callers to process
if one exists.

The function ensureVRGManifestWork is to ensure ManifestWork for VRG
exists and update its mutable fields appropriately. Added a latch to
ensure that the MW for VRG that needs to be ensured is present, and that
it is reported as delivered to the ManagedCluster (using a check to see
if a view is present).

The changes to ensureVRGManifestWork also includes NOT creating a VRG
from a view, as that should be ensured by the adoptOrphanVRG function
at the start of reconciling a DRPC.

The caller startDeploying, which calls createVRGManifestWork, now checks
for an exists error and proceeds to update the Placement. This is done as
any errors in updating placement would send the reconciler back to creating
the VRG, which as it exists would keep failing. Other callers ensure that
the VRG exists and if so update it, rather than calling create.

Signed-off-by: Shyamsundar Ranganathan <[email protected]>

Update works to ensure VRG is updated with peerClasses that it requires,
based on reported PVCs that the VRG is attempting to protect. If a VRG
is attempting to protect a PVC for which is is lacking a peerClass and
that is available as part of the DRPolicy its peerClasses are updated.

For existing peerClasses the VRG information is not updated, this is done
to avoid any protection mechanism conflicts. For example, if a VRG
carried a peerClass without the replicationID (ie it would choose to
protect the PVC using Volsync and VolumeSnapshots), then it is not
updated with a peerClass that NOW supports native VolumeReplication, as
that would void existing protection.

To change replication schemes a workload needs to be DR disabled and then
reenabled to catch up to the latest available peer information for an SC.

Signed-off-by: Shyamsundar Ranganathan <[email protected]>

Secondary VRG should carry the same peerClass information as the Primary
VRG, such that on action changes that promotes the Secondary to a Primary
the same peerClasses are used to recover and protect the PVCs.

This commit addresses updating Secondary VRG with Primary VRG peerClasses
for async cases when Volsync is in use.

Currently VRG as Secondary is created when there are any PVCs protected
by Volsync. Once the issue of mixed workloads is addressed, a Secondary
VRG would exist for all cases, VolRep and sync DR setups as well. This
will ensure that in all cases the Secondary peerClasses are a copy of
the Primary.

Signed-off-by: Shyamsundar Ranganathan <[email protected]>